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Dr.  Christine  Julien 
Abstract 

As  ubiquitous  computing  applications  become  pervasive,  the  need  for  wireless,  mobile  coordination  among 
dynamic  participants  is  becoming  a  central  focus  of  any  application.  TVaditionai  distributed  computing  so¬ 
lutions  require  mobile  parties  to  communicate  to  a  central  location  (generally  on  an  infrastructure  network) 
before  their  data  can  be  shared  with  other  mobile  parties.  In  contrast,  ubiquitous  computing  environments 
benefit  from  direct  communication  among  mobile  parties  that  enables  more  efficient  and  speedy  data  shar¬ 
ing.  Dynamic  ubiquitous  coordination  environments  abound  in  varying  application  domains.  For  example, 
an  autonomously  coordinating  fleet  of  unmanned  aerial  vehicles  requires  significant  direct  interactions  among 
the  UAVs  and  perhaps  among  sensors  on  the  ground.  Future  battlefields,  construction  sites,  and  repair  zones 
will  harbor  large  numbers  of  information-providing  devices  whose  data  can  be  shared  for  safety  purposes  or 
to  make  job  functions  easier  or  more  efficient.  Application  development,  however,  is  not  the  focus  of  this 
project.  Instead,  wc  identify  what  these  applications  have  in  common  (be,  dynamic  environments,  auton¬ 
omy  of  devices,  need  for  coordination,  etc,)  and  encapsulate  this  shared  functionality  within  a  middleware 
infrastructure.  This  middleware  will  be  supported  by  a  a  novel  coordination  model  that  handles  the  extreme 
dynamics  these  environments  exhibit  while  leveraging  the  benefits  of  direct  communication. 

Research  Objective.  The  goal  of  this  research  proposal  is  to  create  a  coordination  model  and  middleware 
for  adaptive  mobile  applications.  To  enable  adaptation,  the  coordination  model  specifically  makes  applications 
and  the  coordination  among  them  context- aware  by  moving  abstracted  information  about  environmental  state 
towards  applications  and  makes  coordination  and  communication  application- aware  by  moving  information 
about  applications*  constraints  and  requirements  toward  communication  protocols.  Ultimately,  the  work  will 
produce  a  tailor  able  adaptive  middleware  that  simplifies  the  programming  of  mobile  applications  without 
restricting  the  flexibility  of  coordination.  This  is  not  another  middleware  model  proposal  The  research  plan 
involves  neither  simple  tweaks  to  existing  solutions  nor  a  Herculean  task  of  combining  many  layers  into  one 
massive  solution.  Instead,  the  project  will  devise  a  truly  dynamic  coordination  model  and  middleware  that 
adapt  on-demand  to  changes  in  the  environment  and  in  application  requirements  or  expectations. 

Approach,  In  contrast  to  existing  middleware  approaches,  our  project  does  not  focus  in  detail  on  rigid 
abstraction  through  layering.  Instead,  %ve  focus  on  the  information  that  can  be  shared  among  these  abstractions 
through  cross -layer  interactions .  We  will  pursue  a  top  down  approach  that  starts  by  creating  programming 
constructs  through  which  application  developers  can  express  their  requirements  for  coordination.  We  will 
then  create  a  dynamic  coordination  model  that  adapts  to  both  application  and  context  information.  This 
coordination  model  includes  a  novel  communication  model  that,  by  using  context  and  application  information, 
dynamically  determines  how  messages  should  be  routed.  Modular  implementations  of  the  communication 
model  can  be  swapped  in,  making  the  middleware  itself  tailorable  to  different  operating  conditions.  Finally, 
we  will  also  create  adaptive  sensing  mechanisms  that  can  tradeoff  the  fidelity  of  sensed  context  information 
for  the  overhead  of  sensing. 

Scientific  Merit,  The  novelty  of  this  work  in  comparison  with  existing  approaches  is  its  dynamism 
based  on  interactions  between  layers  of  abstractions.  This  allows  the  resulting  middleware  to  smoothly  move 
information  between  traditional  layers  of  abstraction  and  allows  components  within  those  layers  to  adapt  their 
behavior  to  their  environment. 

Potential  Impact.  The  project  emphasizes  the  use  of  awareness  to  enable  high- degrees  of  coordination 
among  wirelessly  connected,  distributed  components,  thereby  boosting  the  performance,  efficiency,  respon¬ 
siveness,  and  flexibility  in  comparison  to  existing  approaches.  Such  a  solution  will  make  possible  significant 
amounts  of  coordination  not  previously  possible  in  harsh  network  environments  where  operating  conditions 
such  as  high  degrees  of  mobility  or  low  link  quality  have  previously  prevented  reliable  connectivity. 
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Research  Effort 


1  Introduction 

This  project  targets  the  development  and  deployment  of  wireless  applications  in  domains  that  require 
dynamic  and  adaptive  coordination  among  highly  mobile  devices  and  devices  embedded  in  the  environment . 
Facilities  for  adaptive  coordination  are  essential  to  making  such  applications  responsive,  efficient,  and,  most 
importantly,  largely  autonomous.  Abstraction  through  layering ,  in  which  the  problem  is  subdivided  into 
multiple  manageable  tasks  at  each  layer,  is  the  most  common  and  sensible  approach  to  managing  the  complexity 
of  this  task.  However,  existing  designs  based  on  rigid  abstractions  ignore  a  significant  amount  of  useful 
information  that  can  be  shared  among  layers  for  adaptation  and  increased  performance.  The  impact  of 
this  information  exchange  can  be  enormous  in  providing  an  integrative  platform  for  creating  future  computing 
systems.  Such  systems  will  necessarily  be  defined  by  distributed  resources  whose  connectivity  and  coordination 
must  be  managed  as  an  integral  part  of  building  any  complete  application. 

Instead  of  focusing  on  the  rigid  separation  of  functionality  into  behavioral  layers,  this  project  will  focus 
on  developing  novel  ways  of  transiting  information  between  components  at  different  layers  of  abstraction. 
Specifically,  the  project  provides  context-awareness  from  the  physical  and  network  worlds  and  application- 
awareness  from  the  logical  application  world.  The  former  provides  all  components  in  a  system  (i.e.,  from 
communication  protocols  to  applications)  the  ability  to  adapt  their  behavior  to  a  changing  situation.  The 
latter  (i.e.,  application-awareness)  allows  a  system's  coordination  and  communication  to  respond  to  changing 
application  requirements.  The  project  proposes  new  coordination  models,  algorithms,  and  protocols  and 
throughout  emphasizes  the  use  of  awareness  to  enable  intelligent  coordination  among  networked  components, 
thereby  boosting  a  system's  autonomy,  performance,  efficiency,  expressiveness,  and  flexibility  in  comparison 
to  existing  approaches. 

We  provide  two  applications  that  moti¬ 
vate  the  need  for  awareness  at  these  varying 
levels.  Within  Section  2,  we  discuss  not  only 
these  applications  but  also  how  such  appli¬ 
cations  are  addressed  using  current  state- 
of-the-art  technology.  Section  3  overviews 
the  project's  intended  solution  strategy  be¬ 
fore  Section  4  explores  the  project’s  specific 
research  approach  and  intended  results  in 
more  detail.  Throughout,  we  compare  our 
proposed  approach  with  other  existing  endeavors.  We  conclude  with  a  discussion  of  the  potential  impact  of  a 
successful  project. 

2  Motivating  Scenarios 

The  first  application  scenario  motivating  this  project  involves  enabling  coordination  among  unmanned 
aerial  vehicles  (UAVs)  that  may  be  deployed  for  military,  scientific,  and  civilian  purposes,  including  border 
patrol,  data  gathering,  reconnaissance,  surveillance,  and  search  and  rescue  missions.  The  coordination  con¬ 
structs  this  project  will  generate  will  ease  the  development  of  applications  that  require  coordination  among 
UAVs  and  vehicles,  soldiers,  agents,  or  sensors  on  the  ground,  as  depicted  in  Figure  1.  Such  scenarios  de¬ 
mand  that  the  components  automatically  communicate,  self-organ  ize,  collaborate,  and  undertake  decisions 
autonomously,  thereby  adapting  to  achieve,  for  example,  the  best  surveillance  coverage  within  a  designated 
area.  The  availability  of  information  about  coordinating  partners  and  the  quality  and  duration  of  communi¬ 
cation  with  them  is  essential  to  planning  in  this  type  of  application.  The  result  of  such  application  support 
would  be  a  coordinated,  intelligent,  and  largely  autonomous  fleet  of  UAVs.  With  current  technologies,  UAVs 
deployed  for  any  task  are  almost  entirely  operator  controlled.  In  addition,  moving  information  from  one  UAV 


Figure  1:  Coordinating  UAVs,  Soldiers,  and  Sensors 
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to  another  is  not  done  directly;  information  must  first  be  transmitted  to  a  ground  station  where  it  is  processed 
by  an  operator  before  it  can  impact  the  behavior  of  another  UAV  (through  explicit  operator  control).  Direct 
communication  among  the  UAVs  (potentially  augmented  with  information  from  sensors  in  the  environment) 
enables  more  rapid  response  to  changing  situations.  Active  coordination  using  this  direct  communication 
makes  the  UAV  fleet  more  autonomous  and  adaptive.  In  addition,  minimizing  the  required  physical  com¬ 
munication  using  direct  connections  between  mobile  and  embedded  devices  can  help  relieve*  the  overtaxed 
communication  links  present  in  today’s  military  wireless  networks. 

Our  second  motivating  scenario  enables  real-time 
coordination  and  collaboration  of  workers  in  a  dy¬ 
namic  information  environment.  This  scenario  envi¬ 
sions  a  set  of  workers  distributed  around  a  hangar  per¬ 
forming  maintenance  on  a  variety  of  aircraft  systems 
across  many  aircraft.  Both  equipment  and  informa¬ 
tion  must  be  shared  among  maintained  in  this  envi¬ 
ronment.  The  latter  includes  information  collected  au¬ 
tomatically  by  an  airplane  during  its  mission,  repairs 
required  or  requested  for  a  particular  craft,  the  sta¬ 
tus  of  repairs,  an  aircraft’s  maintenance  history,  etc. 

Equipment  shared  among  the  maintained  includes  not 
only  the  aircraft  but  also  expensive  equipment  within 
the  hangar  used  for  both  diagnostics  and  repair.  In 
addition,  direct  wireless  connectivity  from  the  floor  of 
the  hangar  to  the  parts  storage  and  ordering  facilities 
can  increase  the  speed  and  efficiency  of  repairs.  Finally,  maintenance  officers  oversee  the  progress  of  all  repairs 
and  must  sign  off  on  complete  repairs.  With  current  technologies,  maintenance  activities  are  minimally  aided 
by  computing  technologies  through  a  laptop-like  interface  that  can  store  digital  copies  of  maintenance  records 
and  manuals.  This  interface  provides  only  asynchronous  (or  off-line)  collaboration,  achieved  through  docking 
the  laptop  at  certain  times  or  at  the  end  of  the  day.  The  coordination  constructs  this  project  proposes  would 
augment  existing  capabilities  with  real-time  collaboration  among  dynamic  parties,  allowing  maintained  to 
keep  a  consistent  picture  of  the  status  of  on-going  repairs  and  availability  of  other  personnel,  equipment,  and 
parts.  This  application  is  similar  in  flavor  to  the  vision  of  the  intelligent  construction  site  [13],  an  area  in 
which  the  PI  and  her  collaborators  have  already  developed  a  prototype  coordination  middleware  [16,  17] .  The 
similarity  between  these  domains  offers  a  unique  opportunity  to  test  the  results  of  this  proposed  project  in  a 
similar  yet  less  mission  critical  environment  prior  to  deployment. 

3  Overview  of  Solution  Strategy 

While  the  above  applications  provide  motivation  for  this  project’s  research,  the  ultimate  goal  is  not  to 
develop  these  applications  but  to  make  it  possible  and  simple  to  create  such  dynamic  applications  using 
efficient  and  intuitive  programming  constructs.  Specifically,  this  project  will  provide  adaptive  coordination 
through  precise  application- awareness  and  efficient  context-awareness.  The  project  will  result  in  a  middleware 
that  will  provide  a  programming  interface  to  application  developers  that  enables  the  rapid  development  of 
highly-adaptive  applications. 

In  the  model  and  system  this  project  will  create,  awareness  moves  information  about  the  application  and  the 
context  through  three  hierarchical  layers:  1)  application  coordination ,  the  major  interface  to  the  application, 
where  application  requirements  are  collected  and  high-level  coordination  occurs;  2)  communication ,  through 
which  tailored  wireless  communication  protocols  enable  intelligent  creation  and  maintenance  of  groups  of 
coordinating  devices;  and  3)  context  collection ,  which  efficiently  and  transparently  collects  and  abstracts  the 
context  information  dynamically  deemed  to  be  necessary  or  beneficial.  The  work  proposed  in  this  project 
complements  an  ongoing  collaboration  with  Dr.  Sriram  Vishwanath  (see  PRINCIPAL  Investigator  TrME, 
current  project  CSR-SMJ:  ACLI-ware)  that  aims  to  use  cross- layer  interactions  to  allow  information  about 
physical  wireless  channel  state  to  impact  applications  and  to  allow  applications  to  impact  how  wireless  channel 
state  is  sensed.  In  contrast,  this  proposed  project  focuses  specifically  on  the  coordination  gains  that  can  be 
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Figure  2:  A  Coordinated  Maintenance  Environment 
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achieved  when  one  has  access  to  context  information  and  how  coordination  constructs  can  provide  application 
preferences  to  underlying  system  components. 

Section  4  of  this  proposal  describes  the  specific  intended  research  contributions.  In  the  remainder  of  this 
section,  we  first  discuss  the  types  of  application  and  context  information  that  can  be  shared  among  traditional 
system  layers  to  improve  coordination  autonomy  and  efficiency. 

3.1  Application-awareness 

Interactions  that  fall  under  the  guise  of  application- awareness  distribute  information  about  application 
behavior  and  requirements  to  the  underlying  model  and  middleware  components. 

•  Application- awareness  for  application  coordination:  to  be  useful  to  applications,  the  lower- layer  model 
and  middleware  components  must  provide  a  usable  interface  for  developers  to  express  their  constraints 
and  thereby  influence  the  middleware’s  behavior.  The  project  will  create  expressive  coordination  con¬ 
structs  that  allow  applications  to  define  policies  related  to  their  expectations  and  allowable  tradeoffs. 
This  information  can  enable  adaptive  coordination  through  dynamic  selection  of  coordinating  partners. 
This  work  will  build  on  my  existing  work  in  using  traditional  coordination  languages  for  expressing  such 
policy  parameters. 

*  Application/coordination- awareness  for  communication:  applications’  reliability  requirements  and  pref¬ 
erences  can  also  be  used  to  determine  the  best  communication  links  and  routing  paths  to  use  to  maintain 
connectivity  of  a  coordinating  pair  or  group.  The  clustering  models  and  protocols  this  project  will  develop 
will  use  application-provided  information  to  intelligently  adapt  group  formation  and  communication  pro¬ 
tocols  to  provide  efficient  and  responsive  implementations  that  exactly  match  applications'  requirements 
without  incurring  more  than  the  necessary  communication  overhead. 

•  A pplication/cornmvnication- awareness  for  context  sensing :  information  about  the  physical  and  network 
environments  can  be  sensed  at  varying  levels  of  granularity.  One  can  devote  a  lot  of  energy  to  deter¬ 
mining  context  information  to  a  high  degree  of  accuracy  only  for  the  information  to  provide  little  to  no 
benefit  at  higher  layers.  In  addition,  context  sensing  can  be  very  expensive  because  it  generates  added 
communication  overhead.  We  will  devise  context  sensing  techniques  that  respond  directly  to  application 
requirements  to  collect  only  context  information  that  applications  or  communication  protocols  can  use 
while  incurring  as  little  additional  overhead  as  possible. 

3.2  Context-awareness 

In  the  opposite  direction  from  application- awareness,  all  three  levels  can  also  nse  information  about  the 
physical  and  network  environments  to  adapt  their  coordination  behavior, 

*  Context- awareness  for  context  sensing:  at  first  glance  it  may  seem  strange  that  the  context  sensing  itself 
should  adapt,  but  information  sensed,  for  example,  about  the  network  conditions  can  tell  a  context 
sensing  algorithm  to  use  strictly  passive  sensing  (when  network  activity  is  high)  or  to  use  a  partially 
active  approach  (because  little  other  communication  is  occurring).  This  project  will  model  the  use  of 
such  context  information  and  will  create  context  sensing  protocols  that  can  specifically  respond  to  such 
information. 

•  Context- awareness  for  communication:  group  formation  and  communication  algorithms  can  benefit  sig¬ 
nificantly  from  information  regarding  what  other  devices  are  available.  In  addition,  information  about 
the  physical  world  (e.g.,  how  fast  devices  are  moving)  and  the  network  world  (e.g.,  how  congested  the 
network  is)  can  help  select  the  most  efficient  communication  approach  for  a  set  of  operating  conditions. 
This  work  will  define  an  infrastructure  that  allows  effective  communication  of  exactly  the  context  infor¬ 
mation  required  by  communication  protocols.  In  addition,  we  will  create  a  communication  suite  that 
adapts  itself  to  these  changing  conditions  to  provide  reliable  connectivity  even  in  harsh  environments. 

*  Context- awareness  for  application  coordination:  finally,  applications  can  use  context  information  to 
determine  what  information  to  send  when.  In  dynamic  networks,  connectivity  must  be  leveraged  op¬ 
portunistically  because  there  is  no  guarantee  of  persistent  connectivity.  When  a  network  is  congested 
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or  the  link  quality  is  low,  only  high  priority  information  should  be  transmitted.  Applications  can  also 
adjust  their  data  fidelity  in  response  to  context  (e,g.,  to  send  low  quality  video  when  only  low  bandwidth 
links  are  available).  We  will  develop  a  language  to  communicate  context  and  connectivity  information 
to  applications  and  a  framework  within  our  middleware  that  applications  can  use  to  respond  to  such 
context  information. 

3.3  Benefits  of  the  Approach 

By  undertaking  a  solution  strategy  founded  on  bi-directional  interactions  among  physical  and  network 
components  and  application  components,  this  project  will  provide  several  benefits  over  related  approaches 
that  investigate  either  only  protocols  within  single  layers  of  abstractions  or  approaches  that  create  awareness 
in  only  one  direction.  First,  as  demonstrated  by  the  vast  differences  in  our  motivating  applications,  this 
project's  broader,  integrative  perspective  unifies  disparate  applications  within  a  single  system,  making  system 
maintenance  and  updating  much  simpler.  In  addition,  the  resulting  model's  ease  of  understanding  and  the 
system’s  ease  of  use  encourage  rapid  adoption  and  deployment  of  cutting  edge  applications  that  can  share  a 
single  underlying  system  infrastructure. 

4  Research  Approach  and  Nature  of  Expected  Results 

As  intimated  above,  we  divide  the  research  tasks 
into  two  areas;  concerns  related  to  creating  a  com¬ 
plete  and  correct  model  of  the  ways  applications 
should  interact  and  share  information  across  tradi¬ 
tional  protocol  layers  and  concerns  related  to  pro¬ 
viding  a  practical  realization  of  these  models  in  a 
dynamic  middleware*  Instead  of  handling  model¬ 
ing  and  systems  issues  as  separate  tasks,  we  inte¬ 
grate  both  our  discussion  and  intended  investigation 
of  them  to  ensure  both  that  our  system  realization 
is  grounded  in  formal  underpinnings  and  that  our 
model  is  in  fact  implement  able.  Figure  3  shows  the 
areas  in  which  the  research  contributions  described 
below  fall.  We  describe  these  areas  from  the  top 
down,  focusing  on  the  provision  of  application-  and 
context-awareness  depicted  to  the  left  and  right  sides  of  this  figure  instead  of  on  the  traditional  requests  and 
replies  found  between  hierarchical  layers.  These  aspects  of  awareness  differentiate  this  project  from  other 
mobile  coordination  efforts.  At  the  top  of  the  figure,  high-level  specifications  of  interactions  provide  an  in¬ 
tuitive  interface  to  application  programmers,  allow  applications  to  provide  information  to  both  coordination 
and  communication  constructs  (on  the  left),  and  allow  applications  to  respond  to  context  information  {on  the 
right).  In  the  second  step,  we  define  a  coordination  model  that  is  largely  hidden  from  the  application  devel¬ 
oper  (through  the  high-level  specification  interface)  but  provides  an  important  abstraction  of  the  underlying 
physical  world.  The  coordination  model  adapts  to  information  about  the  environment  and  network  states  and 
provides  awareness  of  coordination  requirements  to  communication  protocols  through  a  novel  encapsulation 
of  communication  behavior.  The  communication  model  provides  a  standard  manner  of  supporting  coordina¬ 
tion,  and  it  is  realized  by  concrete  imp  lament  at  ions  of  communication  protocols.  While  these  communication 
protocols  can  adapt  to  application  requirements  through  information  fed  from  the  coordination  model,  they 
also  provide  valuable  information  about  the  state  of  the  network  and  thereby  enable  context-awareness  for  the 
upper  layers.  Finally,  an  environmental  sensing  module  augments  the  network  awareness  to  provide  complete 
context-awareness . 

4,1  High-Level  Specifications  of  Interactions:  Enabling  Application- Awareness 

At  the  level  closest  to  the  application  developer  who  will  use  our  integrated  coordination  system,  we  will 
provide  constructs  that  enable  high-level  specifications  of  interactions  among  dynamic  mobile  devices  This 
portion  of  the  proposed  work  is  founded  on  our  existing  application  sessions  model  [23]  which  formalizes  a  suite 
of  interactions  among  devices  in  a  mobile  computing  environment.  These  interactions  range  from  short-lived 


Figure  3:  Layering  and  Awareness 
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interactions  among  two  parties  to  long-lived  interactions  coordinating  a  group  of  participating  entities.  By  its 
construction,  the  model  explicitly  separates  the  user  program  {i.e.,  the  local  behavior  of  a  particular  device) 
from  interactive  session  management,  which  the  application  can  then  delegate  to  an  underlying  coordination 
system.  The  only  information  shared  between  the  two  are  a  specification  (spec)  of  the  desired  coordinating 
partner  or  information,  and  a  handle  (p)  that  allows  the  application  to  access  the  resource  to  which  the 
underlying  infrastructure  connects  it.  To  date,  this  application  sessions  model  includes  fonr  types  of  sessions. 
The  query  session  exemplifies  a  simple,  one-time  request  for  a  piece  of  data  from  a  remote  party.  The  provider 
session  connects  the  application  to  a  particular  remote  device  satisfying  some  requirement.  The  infrastructure 
subsequently  maintains  this  connection  even  in  the  face  of  mobility  or  other  dynamics.  The  type  session 
connects  the  application  to  a  remote  device  that  satisfies  some  requirement.  As  mobility  or  other  dynamics 
cause  changes  in  the  environment,  the  application  can  be  reconnected  to  a  different  coordinating  partner  that 
also  satisfies  the  initial  requirement.  This  session  type  provides  more  flexibility  within  the  implementation  of 
the  underlying  coordination  model.  Finally,  the  group  session  connects  the  requester  to  all  communicating 
parties  that  satisfy  some  requirement  (e.g.,  UAVs  within  a  certain  area).  As  dynamics  cause  this  set  to  change, 
the  underlying  coordination  infrastructure  updates  the  participants  in  the  group  session.  For  brevity,  we  show 
the  formalization  of  only  the  type  session  here;  complete  formalizations  can  be  found  in  [23]; 

p  spec 

^  p  =  p* .(pf  1=  spec  A  pft  connected) 
while  p  e  do 

{await  -^.connected  p  =  p',(p'  H  spec  A  p'. connected)) 

od 

The  expression  in  the  box  denotes  the  particular  session  semantic,  in  this  case  the  type  session  is  indicated 
using  an  open  arrow  to  assign  the  specification  spec  to  the  handle  p.  The  selection  of  a  coordinating  partner 
matching  the  requirement  uses  non- deterministic  assignment  [2]  to  indicate  that  a  partner  is  selected  from  any 
that  satisfy  the  specification.  A  statement  x  :=  x*~Q  assigns  to  x  a  value  xf  nondeterministically  selected  from 
among  the  values  satisfying  the  predicate  Q .  If  such  an  assignment  is  not  possible,  the.  statement  aborts;  we 
assume  this  results  in  assigning  e  (a  null  value)  to  x.  The  entails  (^)  relation  indicates  that  a  remote  device 
satisfies  a  specification,  i.e.,  in  p  j=  spec ,  remote  device  p  satisfies  spec .  In  the  type  session  specification  above, 
the  requester  is  initially  connected  to  any  remote  device  that  satisfies  the  specification  and  is  connected  to 
the  requester.  If  this  coordinating  partner  becomes  disconnected,  the  type  session  attempts  to  connect  to  any 
other  remote  device  that  happens  to  be  connected  and  satisfy  the  specification. 

Within  this  proposed  project,  we  will  use  this  existing  work  as  a  foundation  for  creating  session  speci¬ 
fications  that  communicate  more  than  just  functional  requirements  from  the  application  to  the  underlying 
coordination  infrastructure  and  communication  protocols.  These  new  constructs  will  provide  much  of  the 
information  that  our  vision  of  application- awareness  requires.  We  envision  augmenting  application's  specifi¬ 
cations  of  interactions  with  a  preference  function  that  can  encapsulate  these  non-functional  requirements.  For 
example,  a  type  session’s  specification  may  become: 

p  <$=  spec/  f 

=  p  —  p* .{p*  ^  spec  A  p\ connected  A  (V7T  :  tt  |=  spec  ::  f(pf)  <  /(tt))) 
while  p  ^  edo 

(await  ^.connected  V  {3tt  :  ?r. connected  A  tt  |=  spec  A  f(n)  <  /(p))  — ► 
p  =  p'.(p'  h  spec  A  p'.connected  A  (Vtt  :  i r  \=  spec  ::  f{pr)  <  /(tt))) 
od 

In  this  case,  /  is  a  function  that  compares  the  quality  of  two  matching  potential  partners.  Not  only  does 
the  type  session  have  to  ensure  that  it  initially  selects  the  best  partner,  but  it  must  constantly  monitor  the 
available  potential  partners  to  ensure  that  this  match  remains  the  best  one  available.  The  statement  inside 
the  loop  ensures  that  the  requester  is  reconnected  if  a  better  provider  becomes  available. 

In  the  above  example,  the  function  /  makes  the  process  of  incorporating  preferences  simple,  but  several 
subtleties  arise  in  how  the  function  /  should  be  written  and  how  it  should  be  applied  in  all  cases.  In  addition, 
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incorporating  this  constant  monitoring  of  potential  partners  during  a  long-lived  interaction  changes  how  the 
coordination  infrastructure  can  successfully  implement  these  interactions,  as  described  in  more  detail  below. 
Within  this  project,  we  will  investigate  how  to  use  this  preference  function  approach  to  enable  novel  application 
semantics  (e.g.,  a  probabilistic  group  session  that  connects  the  requester  to  some  percentage  of  the  devices 
that  satisfy  the  requirement  or  a  type  session  that  allows  the  requester  to  dictate  conditions  under  which  a 
binding  can  be  reassigned). 

Our  approach  is  similar  in  spirit  to  approaches  that  perform  network  sensitive  service  selection  [IS]  or 
approaches  that  use  Quality  of  Service  (QoS)  to  differentiate  potential  service  providers  [25,  26,  32].  An 
important  distinction  of  our  design,  however,  is  the  placement  of  this  function  in  the  hands  of  the  requester 
and  the  complete  distribution  of  its  evaluation.  Through  the  combination  of  our  specification  mechanics  and 
the  implementation  of  the  evaluation  (described  below),  we  provide  a  novel  evaluation  structure  that  functions 
without  reliance  on  any  central  service  or  third  party  to  assist  in  the  process.  In  addition,  our  approach  to 
constructing  /  will  focus  on  ensuring  the  simplicity  of  its  specification,  a  concern  which  many  of  the  approaches 
above  ignore  due  to  the  fact  that  policies  are  fairly  statically  defined. 

Ultimately,  our  work  in  this  thread  will  result  in  a  usable  interface  for  application  developers  to  easily 
express  their  constraints  and  tradeoffs  with  respect  to  coordination  interactions  in  a  dynamic  environment. 
This  approach  provides  application-awareness  by  allowing  applications  to  place  constraints  on  lower  layers. 
It  also  allows  the  application  to  express  how  context  information  impacts  the  application  layer  and  therefore 
dictates  what  context  information  should  be  collected  and  with  what  fidelity. 

•  Research  Task  #1:  Creation  of  application  sessions  that  allow  different  semantics,  encapsulate  the 
requester’s  non-functional  requirements  into  the  formalizations  of  the  interactions,  and  provide  intuitive 
programming  constructs  on  top  of  the  underlying  coordination  middleware. 

4.2  Supporting  High-Level  Interactions  through  a  Novel  Coordination  Model 

In  this  section,  we  discuss  the  research  is¬ 
sues  involved  in  creating  a  complete  coordina¬ 
tion  model  to  underly  the  high-level  interactions 
specified  through  the  constructs  described  above. 

This  new  model  will  be  founded  on  Linda-like  tu¬ 
ple  spaces  [9,  14]  that  enable  content  based  coor¬ 
dination  among  distributed  parties.  We  combine 
the  notion  of  a  Linda  tuple  space  with  the  global 
virtual  data  structures  model  [29]  in  a  manner 
similar  to  Lime  [28]  and  EgoSpaces  [22]  by  associ¬ 
ating  a  local  tuple  space  with  each  mobile  device 
in  the  network.  This  tuple  space  contains  tuples 
with  the  information  a  particular  device  shares 
with  other  networked  devices.  A  global  virtual 
tuple  space  is  dynamically  defined  to  contain  the 
contents  of  all  tuple  spaces  of  devices  that  are  si¬ 
multaneously  connected.  It  is  this  dynamic  global  virtual  tuple  space,  instead  of  a  single,  centralized  one,  over 
which  interactions  in  our  coordination  model  operate.  Figure  4  shows  how  this  global  virtual  data  structure 
abstraction  dynamically  creates  coordination  groups  based  on  connectivity. 

Information  about  devices  in  the  network  and  the  data  they  create  is  stored  in  the  device’s  local  tuple 
space  in  tuples.  Each  device  may  have  a  single  tuple  that  describes  itself  and  may  produce  more  tuples  that 
change  over  time  as  the  data  it  collects  or  the  services  it  can  offer  change.  From  our  first  motivating  example, 
each  UAV  may  contain  a  tuple  that  describes  the  region  on  the  ground  that  the  UAV  can  currently  observe. 
A  group  session  defined  over  a  set  of  connected  UAVs  could  generate  a  complete  picture  of  the  currently 
observed  ground  area.  From  our  second  example,  the  following  tuple  stored  in  an  aircraft’s  local  tuple  space 
may  indicate  an  anomalous  event  that  occurred  during  that  aircraft’s  mission: 

{(euent,  system  failure),  ( system ,  avionics), . . .) 


device  3 


device  5 

i 


ts  5 


* 

device  4 


‘igure  4:  Dynamic  coordination  groups  based  on  global 
irtual  data  structures.  Devices  I,  2,  and  3  form  a  group; 
eviees  4  and  5  form  a  second  group. 
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Each  pair  in  the  tuple  is  a  field  and  contains  a  portion  of  the  tuple's  information.  In  this  case,  the  ellipses 
indicates  that  the  event  information  may  be  augmented  with  additional  details  that  pertain  to  the  particular 
failure  (e,g*,  the  time  of  the  incident,  particular  components  implicated,  etc.).  At  the  lowest  level,  requests  for 
data  take  the  form  of  templates  over  tuples  that  specify  the  requirements  for  a  matching  tuple.  For  example, 
an  avionics  maintainer  in  the  hangar  may  search  for  avionics  mission  events  using  the  following  template, 
which  requires  a  matching  tuple  to  have,  at  a  minimum,  two  fields  that  satisfy  the  stated  restrictions: 

{( event,  *),  (system,  =  avionics)) 

This  template  matches  any  event  that  occurred  in  the  avionics  systems,  including  the  tuple  shown  above. 

This  use  of  semi-structured  data  [1]  to  describe  data  and  requests  for  data  is  not  novel  to  our  particular 
approach  and  has  been  used  in  service  description  languages  [4,  10,  12]  and  other  tuple-based  systems  [8,  20,  28], 
What  is  novel  about  our  approach  is  how  we  incorporate  the  application-awareness  made  possible  by  the 
interaction  semantics  described  above  into  the  tuple-based  coordination  model.  In  our  model,  interaction 
requests  generated  by  an  application's  use  of  the  high-level  interaction  semantics  above  are  encapsulated 
in  active  tuples ,  similar  to  those  first  introduced  in  Linda  [9].  An  active  tuple  differs  from  the  previously 
described  passive  tuples  in  that  it  can  contain  uncompleted  computation.  In  our  new  coordination  model, 
this  computation  is  specifically  the  series  of  steps  that,  in  conjunction  with  a  communication  protocol,  move 
the  active  tuple  to  the  appropriate  location  (be.,  where  the  desired  information  resides),  evaluate  the  request 
against  available  coordinating  partners,  and  send  a  result  back  to  the  requester.  The  active  tuple  is  also 
used  to  transit  application  information  to  the  coordination  infrastructure  and  communication  protocols.  In 
general,  an  active  tuple  contains  some  unevaluated  aspect  when  it  is  placed  in  the  requester's  local  tuple 
space*  The  evaluation  of  the  active  tuple  is  performed  as  it  is  moved  by  the  communication  model  and 
ultimately  resolved  to  connect  the  requester  to  a  remote  coordinating  party.  The  final  component  of  our  new 
coordination  model  is  this  modular  communication  model  that  causes  movement  of  active  tuples,  resulting  in 
their  successful  evaluation  and  the  return  of  responses  to  requests.  Together  the  above  components  constitute 
a  complete  coordination  model  that  directly  supports  the  framework’s  interactive  constructs  described  in  the 
previous  section.  Understanding  and  incorporating  these  individual  components  into  a  complete  model  is  a 
research  task  in  its  own  right;  in  the  next  two  sections  we  investigate  the  use  of  active  tuples  and  modular 
communication  in  more  detail. 

4*3  Incorporating  Application-  and  Context- A  wareness  into  Active  Tuple  Evaluation 

The  functional  requirements  for  a  coordination  interaction  (i.e.?  properties  of  the  coordinating  partner 
or  information  to  be  shared)  are  captured  in  the  Interaction’s  semi-structured  data  specification  which  the 
communication  model  described  below  moves  through  the  network  until  it  finds  a  match.  Non-functional 
requirements  such  as  application-  or  context- awareness  are  instead  captured  within  the  active  tuple  itself.  To 
accomplish  this,  part  of  the  unevaluated  portion  of  the  active  tuple  instructs  the  communication  protocol 
on  how  to  forward  the  active  tuple  through  the  network  based  on  application  preferences  or  the  state  of  the 
network  or  physical  environment.  Specifically,  it  is  at  this  point  that  the  coordination  model  takes  advantage 
of  the  application  information  encapsulated  in  the  high-level  interaction  specification  through  the  preference 
specification  introduced  as  part  of  Research  Task  #1. 

Within  the  scope  of  application-awareness,  not  only  should  information  from  the  application  requesting 
the  coordination  impact  the  evaluation,  but  this  process  must  also  be  aware  of  properties  of  potential  coor¬ 
dinating  partners’  applications*  If  a  request  finds  multiple  potential  partners  that  could  satisfy  the  request, 
aspects  of  the  potential  partner  should  be  used  to  help  determine  which  is  the  best  option.  For  example,  if 
a  maintainer  is  searching  for  a  particular  piece  of  equipment  to  use  for  a  repair,  the  request  should  prefer 
equipment  that  is  not  already  in  use  for  another  repair.  From  the  perspective  of  the  requester,  aspects  of  the 
application  that  may  impact  the  process  of  selecting  coordinating  partners  might  include  aspects  such  as  the 
proximity  of  the  coordinating  partner  (i.e.,  location-dependent  interactions  tend  to  favor  closer  partners)  or 
the  coordinating  partner's  relative  mobility  (e*g*,  if  a  UAV  needs  to  coordinate  with  one  other  nearby  UAV, 
it  may  prefer  the  stable  connection  to  a  UAV  moving  in  the  same  direction  at  the  same  speed).  In  addition, 
the  potential  partner  may  have  requirements  that  a  request  must  meet  before  the  partner  will  coordinate. 
Before  accepting  a  coordination  interaction,  a  potential  partner  may  evaluate  its  current  battery  power  (since 
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communication  expends  valuable  energy)  or  its  load  (be.,  the  number  of  other  coordination  connections  it  is 
already  supporting). 

Finally,  because  applications  like  those  described  in  Section  2  are  supported  by  mobile  ad  hoc  networks  in 
which  the  nodes  themselves  serve  as  routers  for  connections  between  devices  that  are  not  directly  connected, 
the  process  of  moving  active  tuples  towards  potential  coordinating  partners  should  also  account  for  the  state 
of  the  intermediate  network.  That  is,  the  way  coordination  occurs  should  also  be  context- aware.  For  example, 
the  latency  of  the  end-to-end  network  connection,  the  nnmber  of  network  hops  required  to  connect  coordinat¬ 
ing  partners,  the  battery  power  available  on  the  intermediate  nodes  to  support  the  connection,  etc.,  should 
all  factor  into  whether  a  particular  coordination  partnership  is  established.  From  an  implementation  perspec¬ 
tive,  this  is  accomplished  by  hooking  the  coordination  model  into  the  underlying  context-awareness  provisions 
through  active  tuple  evaluations.  When  active  tuples  reach  an  unevaluated  portion  of  code  that  requires 
context  information,  the  context-sensing  components  (discussed  in  Section  4.5)  kick  into  gear  to  generate  and 
return  the  required  information.  The  result  can  determine,  for  example,  whether  or  not  the  communication 
protocol  continues  to  forward  the  particular  active  tuple.  This  movement  of  active  tuples  to  support  coor¬ 
dination  has  been  explored  in  systems  in  addition  to  the  original  Linda  model.  X-Klaim  [5]  used  active 
tuples  to  explicitly  code  movement  of  mobile  agents  from  one  named  location  to  another.  Closer  to  our  work, 
TOTA  [27]  enabled  active  tuples  to  themselves  carry  communication  protocol  information  that  determines 
how  they  should  be  propagated.  We  explicitly  separate  the  communication  modules  from  the  coordination 
components  to  create  a  more  modular  and  adaptive  system.  In  our  system,  the  active  tuples  influence  the 
routing  protocol  based  on  application-  and  context-awareness  but  do  not  explicitly  control  communication.. 

To  satisfy  all  of  these  concerns,  we  will  divide  the  preference  function  introduced  in  Section  4.1  into  three 
partial  functions;  fa{p) i  which  defines  the  cost  to  the  application  requester  a  of  selecting  a  particular  partner 
p;  fp(a)7  which  defines  the  cost  to  partner  p  of  coordinating  with  the  requesting  application  a;  and  /n(a,p), 
which  defines  the  cost  to  the  network  to  support  the  coordination  between  a  and  p .  In  combination,  the  overall 
preference  function  /  from  Section  4.1  is; 

/(a.p)1  =  a/a(p)  +  pfp(a)  +  ufn(a,p) 

where  a)  p,  and  v  are  system-specified  constants  that  weight  the  input  of  different  participants.  The  coordi¬ 
nating  partner  that  best  satisfies  this  function  at  any  given  instant  has  a  cost  of: 

Coptimai  =  (min  a,p  :  p  |=  spec  ::  /(o,p))2 

Ail  of  the  partial  cost  functions  (fa(p)i  /p(a),  and  /n(a,p))  return  values  between  0  and  I,  and  a  +  p  +  v  =  I, 
so  that  the  result  of  evaluating  the  global  preference  function  is  a  value  between  0  and  1.  Each  of  the  partial 
cost  functions  can  also  return  oo,  which  effectively  vetoes  the  particular  coordination  interaction. 

As  part  of  this  proposed  work,  these  pieces  of  the  preference  function  must  be  incorporated  into  the  active 
tuples  that  carry  and  evaluate  requests  for  coordination  connections.  Our  initial  work  in  this  area  [19]  serves  as 
a  starting  point  for  injecting  our  coordination  model  with  application-  and  context-awareness  by  representing 
these  functions  as  unevaluated  portions  of  active  tuples.  As  an  active  tuple  carrying  a  request  is  moved  through 
the  network  by  the  communication  protocol  described  next,  these  functions  will  be  incrementally  evaluated. 
The  incremental  evaluation  incorporates  both  application- awareness  (where  information  comes  from  the  re¬ 
quester’s  specified  preferences  and  information  about  the  potential  partner’s  application  available  in  its  local 
tuple  space)  and  context- awareness  (where  the  information  comes  from  passive  sensing  from  communication 
protocols  and  hybrid  passive/active  sensing  from  environmental  sensors,  as  described  below). 

•  Research  Task  #2;  Representation  of  application-  and  context- awareness  as  unevaluated  portions  of 
active  tuples  that  are  incrementally  evaluated  as  requests  are  moved  through  a  network. 

lln  Section  4.1,  we  wrote  this  function  as  /(p)  because  it  is  written  by  a  particular  application  from  its  perspective,  and  a  is 
therefore  implied.  Here,  for  completeness,  we  include  a  in  the  function. 

2  In  the  three-part  notation :  {op  quantified  ^variables  :  Tange  ::  expression),  the  variables  from  quantified-variabies  take  on 
all  possible  values  permitted  by  range.  Each  instantiation  of  the  variables  is  substituted  in  expression,  producing  a  multiset  of 
values  to  which  op  is  applied,  yielding  the  value  of  the  three-part  expression.  If  no  instantiation  of  the  variables  satisfies  range* 
then  the  value  of  the  three-part  expression  is  the  identity  element  for  op,  e+g+1  true  of  op  is  V  or  0  when  op  is  min. 
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4 .4  Modularizing  Adaptive  Communication 

To  successfully  resolve  interaction  requests  contained  in  active  tuples,  the  coordination  model  must  enable 
communi  c ation  among  requesters  and  potential  coordinating  partners.  In  our  coordination  model,  we  accom¬ 
plish  this  by  moving  the  active  tuples  containing  the  requests.  In  the  highly  dynamic  mobile  environments 
that  characterize  our  applications,  this  process  cannot  rely  on  a  centralized  server  to  resolve  requests  because 
coordination  groups  must  be  formed  by  dynamically  available  coordinating  partners,  as  shown  in  Figure  4. 
Instead,  we  rely  on  techniques  for  mobile  ad  hoc  networks  that  form  opportunistically  given  available  com¬ 
municating  partners  and  change  rapidly  in  response  to  mobility.  In  such  networks,  mobile  devices  must  serve 
as  routers  for  connections  among  other  parties,  e,g.,  in  a  network  of  coordinating  UAVs,  the  UAVs  may  not 
all  be  directly  connected  to  one  another,  and  end-to-end  connections  may  have  to  be  partially  supported  by 
other  UAVs  (as  shown  in  Figure  I). 

Our  communication  model  specifies  the  Interface  between  communication  and  coordination.  This  interface 
defines  the  specific  functionality  that  any  communication  protocol  must  provide  and  enables  our  approach 
to  be  highly  modular,  allowing  one  communication  paradigm  to  be  swapped  out  for  another.  This  can  be 
very  important  in  mobile  computing  environments  where  the  degree  of  mobility  or  other  change  can  radically 
impact  which  communication  approach  provides  the  best  performance  [6,  7,  11], 

The  communication  model  receives  requests  for  communication  by  receiving  active  tuples  from  the  coor¬ 
dination  model.  Part  of  the  unevaluated  portion  of  the  active  tuple  contains  the  specification  of  the  desired 
interaction  partner  (spec  from  Section  4T  above).  When  the  active  tuple  encounters  a  coordinating  partner 
that  matches  this  specification,  this  portion  of  the  active  tuple  will  evaluate,  resulting  in  a  “match"1  for  the 
request.  This  matching  process  is  augmented  by  the  incremental  evaluation  of  the  preference  functions  de¬ 
scribed  in  the  previous  section  which  may  further  restrict  which  partners  match.  The  communication  model 
itself  dictates  that  such  requests  must  be  accepted  by  any  communication  protocol  and  that,  when  matches 
occur,  a  reply  is  generated  and  transmitted  back  to  the  requester.  Depending  on  the  degree  of  application- 
awareness,  the  coordination  model  may  collect  the  replies  before  determining  the  “best**  match  to  deliver  to 
the  application.  Communication  protocols  that  fit  within  the  communication  model  may  perform  this  func¬ 
tion  in  different  ways  appropriate  to  their  particular  situations.  The  research  required  for  the  communication 
model  includes  formalizing  how  its  constructs  fit  with  the  coordination  model  and  what  happens  when  active 
tuples  move  from  one  device  to  another. 

In  addition,  to  provide  a  system  realization  of  our  integrated  coordination  model,  we  will  create  a  suite  of 
communication  protocols  that  adhere  to  this  model  and  successfully  move  active  tuples  to  resolve  application 
requests.  The  first  of  these  communication  approaches,  Cross- Layer  Discovery  and  Routing  (CDR)  [24] ,  is  a 
simple  constrained  flooding  based  protocol  that  uses  the  application  request  itself  to  help  determine  which 
communication  paths  to  use,  CDR  is  a  completely  reactive  routing  protocol  that  performs  communication 
requests  only  on  demand.  In  addition,  CDR  does  not  currently  use  any  context  information  to  help  determine 
which  communication  path  is  the  instantaneous  best  choice.  In  building  a  suite  of  modular  protocols,  we  will 
build  on  CDR  to  create  additional  options  that  perform  a  hybrid  of  reactive  and  proactive  routing  and  use 
context  information  to  adapt  the  routing  decisions.  Group-based  interactions  generally  require  a  different  style 
of  interaction  entirely.  Communication  protocols  for  supporting  group  communication  will  be  founded  on  our 
Network  Abstractions  protocol  [21,  30]  which  encapsulates  a  context-aware  multicast  protocol.  We  will  also 
explore  other  paradigms  of  communication  that  may  prove  viable  in  our  dynamic  networks,  perhaps  based  on 
overlay  routing  or  cluster  based  communication. 

•  Research  Task  #3:  Definition  of  a  model  of  modular  context-  and  application-aware  communication 
that  ultimately  handles  the  distribution  of  requests  for  coordinating  partners  and  data  and  the  funneling 
of  replies  and  information  back  to  requesters. 

*  Research  Task  #4:  Creation  of  a  suite  of  modular  communication  protocols  that  adhere  to  the  model 
defined  in  Research  Task  #3  but  respond  in  different  ways  to  changing  situations  to  produce  context- 
aware  communication. 
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4.5  Adaptive  Context  Sensing 

Application-awareness  is  enabled  by  the  gathering  of  preferences  from  requesters  and  potential  coordinat¬ 
ing  partners  as  detailed  in  the  previous  sections.  The  communication  protocols  and  active  tuple  coordination 
strategy  both  rely  on  the  availability  of  context  information  to  enable  communication  paths  and  coordination 
interactions  to  adapt  to  a  dynamic  environment.  Within  our  model,  context-awareness  comes  in  two  forms: 
environmental  awareness ,  or  knowledge  about  aspects  of  the  physical  world;  and  network- awareness,  or  knowl¬ 
edge  about  the  current  state  of  communication  links.  In  both  cases,  actively  collecting  information  about  the 
environment  can  be  very  expensive  as  it  commonly  generates  extra  communication,  which  can  cause  network 
overhead  and  expend  valuable  battery  power. 

We  define  passive  sensing  as  the  use  of  eavesdropping  on  communication  or  other  network  or  environmental 
tasks  to  infer  context  measurements.  Our  previous  work  has  shown  that  we  can  effectively  and  efficiently 
estimate  a  local  degree  of  mobility  in  such  a  manner  [31].  Other  passive  sensing  efforts  have  used  incoming 
radio  signal  strength  [3]  or  TCP  packet  traffic  information  [33]  to  adapt  local  protocols  to  changing  network 
conditions.  Work  under  the  umbrella  of  this  proposal  will  complete  a  suite  of  such  metrics  that  interact  with 
available  communication  protocols  and  environmental  sensors  to  create  highly  passive  metrics.  These  metrics 
will  be  combined  with  an  environmental  sensing  package  such  as  [15]  to  provide  hybrid  metrics  that  perform  as 
much  passive  sensing  as  possible  but  are  able  to  trade  off  overhead  for  higher  fidelity  context  information.  This 
tradeoff  is  at  least  partially  dictated  by  information  about  the  degree  of  context-awareness  that  applications 
require,  as  specified  in  the  high-level  interactions  specifications.  Our  complete  context  sensing  package  will 
be  incorporated  into  the  framework  as  shown  in  Figure  3.  In  addition  to  defining  the  sensing  suite,  this 
research  will  also  provide  generic  hooks  into  and  out  of  the  context  sensing  package  to  allow  it  to  connect  to 
the  communication  and  coordination  models  to  receive  application-level  information  about  allowable  tradeoffs 
and  to  distribute  sensed  context  information  into  the  coordination  and  communication  protocols  so  they  can 
adapt  as  described  in  the  previous  sections. 

•  Research  Task  #5:  Creation  of  a  suite  of  sensing  protocols  that  provide  a  combination  of  passively 
and  actively  sensed  context  information  at  a  very  low  overhead. 

5  Potential  Impact 

The  research  tasks  embedded  in  this  project  promise  to  introduce  the  benefits  of  combining  application- 
awareness  and  context- awareness  to  create  highly  adaptive  coordinating  applications.  This  starts,  first  and 
foremost,  with  an  expressive  but  simple  programming  interface  presented  to  the  application  programmer. 
Through  this  interface,  the  programmer  can  enable  application-awareness  for  the  lower  levels  and  dictate  the 
kinds  of  context-awareness  that  will  benefit  it  directly.  Behind  this  programming  interface,  a  novel  coordination 
model  provides  the  infrastructure  over  which  applications’  high-level  interactions  can  be  performed.  Two 
key  aspects  of  this  coordination  model,  active  tuples  and  the  modular  communication  model  create  a  highly 
modifiable  and  adaptive  implementation  of  the  coordination  tasks.  Finally,  intelligent  sensing  of  network  and 
environmental  context  provides  much  needed  information  to  dynamically  tailor  the  behavior  of  the  system 
from  the  communication  protocols  up  through  the  application. 

While  this  project  does  propose  novel  algorithms,  models,  and  coordination  techniques,  it  emphasizes  the 
use  of  awareness  to  enable  novel  interactions  among  these  components,  thereby  boosting  the  performance, 
efficiency,  responsiveness,  and  flexibility  in  comparison  to  existing  approaches.  If  successful,  such  an  approach 
will  make  possible  significant  amounts  of  coordination  not  previously  possible  in  harsh  network  environments 
where  operating  conditions  such  as  high  degrees  of  mobility  or  low  link  quality  have  previously  prevented 
reliable  connectivity.  By  sensing  and  adapting  to  context  information,  the  middleware  developed  by  this 
project  will  tailor  application  support  to  particular  operating  conditions,  creating  a  flexible  and  responsive 
coordination  substrate  that  changes  as  the  physical  and  network  environments  change. 
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Adaptive  Coordination  for  Dynamic  Mobile  Sytems 


Principal  Investigator  Time 

The  PI  will  recruit  two  graduate  students  to  work  on  this  project.  These  graduate  students  will  be  paid 
through  stipends  funded  by  the  project,  and  they  will  be  expected  to  work  on  the  projects1  tasks  a  minimum 
of  20  hours  per  week.  In  addition  to  advising  these  students  and  working  on  the  project's  research  in  the 
academic  year,  the  PI  will  also  dedicate  the  eqnivalent  of  100%  of  one  month  of  each  of  the  project's  summers 
to  full-time  work  on  the  project. 

Within  the  Mobile  and  Pervasive  Computing  Lab,  the  PI  is  currently  responsible  for  advising  four  PhD 
students  who  are  funded  through  the  projects  listed  below*  If  funded,  this  project  would  take  over  funding  of 
one  of  these  students  and  add  another  student  to  the  group. 

Current  Projects 

•  CSR-SMA:  ACLI-ware:  Dynamic  Data-Driven  Control  for  Wirelessly  Implemented  Application  Systems 
(7/2006-7/2 008):  NSF  funded,  joint  with  Dr.  Sriram  Vishwanath;  budgeted  at  S 75 ,000  for  two  years, 

1  RA  for  two  years. 

•  Cooperative  Communicatio n  and  A rchitec tures  for  Cro ss-Layer  Coordinate n  ( 7/ 2006- 12/31/2 006 ) :  D ARPA 
funded,  joint  with  Dr.  Scott  Nettles;  budgeted  at  Si  18,401  for  CY  2006,  3  RAs  for  Fall  2006. 

*  Computer  Science  Study  Group  (4/2006-3/2007):  DARPA  funded;  budgeted  at  $87,328  for  one  year, 

3  months  summer  salary  (for  Summer  2006)  and  1  RA  for  Fall  2006. 

•  SGER:  Enabling  Truly  Pervasive  Computing:  Communications  Meets  Software  Engineering  (3/2006- 
2/2008):  NSF  funded;  budgeted  at  8200,000  for  two  years;  covers  11/2  months  summer  salary  (for 
Summer  2007)  and  2  RAs  for  two  years. 

Pending  Projects 

*  Cl- TEAM:  Educating  a  Competitive ,  Cyberinfrastructure-Savvy  Engineering  and  Construction  Work¬ 
force  (NSF):  request  is  for  1/2  month  summer  (for  summer  2008)  and  1  RA  for  two  years  (9/1/2006- 
8/31/2008)* 

*  NeTS-NBD :  Adaptive  Application- Centered  Communication  in  Mobile  and  Pervasive  Computing  (NSF): 
request  is  for  1/2  month  dummer  salary  (for  Summer  2007-2008)  and  1  month  summer  salary  (for 
Summer  2009)  and  2  RAs  for  three  years  (9/1/2006-8/31/2009)* 
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